home *** CD-ROM | disk | FTP | other *** search
/ Light ROM 4 / Light ROM 4 - Disc 1.iso / text / maillist / 1995 / 1095.doc / 000171_owner-lightwav…mail.webcom.com_Tue Oct 3 18:08:14 1995.msg < prev    next >
Internet Message Format  |  1995-11-07  |  3KB
  1. Received: by mail.webcom.com
  2.     (1.37.109.15/16.2) id AA055438894; Tue, 3 Oct 1995 18:08:14 -0700
  3. Return-Path: <owner-lightwave@mail.webcom.com>
  4. Received: from access1.digex.net by mail.webcom.com with ESMTP
  5.     (1.37.109.15/16.2) id AA055288882; Tue, 3 Oct 1995 18:08:03 -0700
  6. Received: (from erniew@localhost) by access1.digex.net (8.6.12/8.6.12) id VAA07650 ; for ; Tue, 3 Oct 1995 21:00:30 -0400
  7. Date: Tue, 3 Oct 1995 21:00:29 -0400 (EDT)
  8. From: Ernie Wright <erniew@access.digex.net>
  9. To: lightwave@mail.webcom.com
  10. Subject: RE: Sparks for Intel!
  11. In-Reply-To: <Pine.3.89.9510031500.B160-0100000@minnie.risd.edu>
  12. Message-Id: <Pine.SUN.3.91.951003205921.7503A-100000@access1.digex.net>
  13. Mime-Version: 1.0
  14. Content-Type: TEXT/PLAIN; charset=US-ASCII
  15. Sender: owner-lightwave@mail.webcom.com
  16. Precedence: bulk
  17.  
  18. Joe Angell wrote:
  19.  
  20. > Since everything is programs in (supposedly) portable C, I assume it
  21. > would be trivial to make those plug-ins for all platforms.
  22.  
  23. Just as easy as making LW itself for all platforms.  Piece of cake.
  24.  
  25. Non-programmers tend not to appreciate how much of a program's code is
  26. devoted to the entirely non-portable user interface.  For professional
  27. products, 75% is on the low side.
  28.  
  29. > The Macros have to be re-programmed from scratch.
  30.  
  31. Not really.  The ARexx interface is duplicated in the plug-in API, so
  32. if you know what you're doing, you can convert Modeler ARexx macros
  33. almost as fast as you can type.  Once converted to C, macro plug-ins
  34. can be moved to all platforms with just a recompile, since they have
  35. no platform-specific user interface code.  This is likely to be the
  36. exception rather than the rule for plug-in development.
  37.  
  38. Steve Bowie wrote:
  39.  
  40. > Still, it seems obvious that not as much effort goes into porting as
  41. > the original creation (IMHO), and further, it likewise seems obvious
  42. > that it should be less complex to program for the relatively limited
  43. > array of Amiga add-ons versus the bewildering plethora of peecee
  44. > graphics cards, cpu's, etc.
  45.  
  46. The question of effort isn't about whether porting is possible, but
  47. whether it's better, easier, and/or more profitable than doing some-
  48. thing else, like enhancing the original product.
  49.  
  50. And if you're programming for Windows, the "bewildering plethora" is
  51. almost entirely hidden from you.  Windows is Windows.  On the Amiga,
  52. it's necessary to "support" third-party display hardware.  In Windows
  53. it's only necessary to write to the Windows API.  Support for a piece
  54. of hardware is provided by the hardware maker.
  55.  
  56. - Ernie
  57.  
  58. --
  59. Ernie Wright <erniew@access.digex.net> sent this message.
  60. To Post a Message           : lightwave@webcom.com
  61. Un/Subscription Requests To : lightwave-request@webcom.com
  62. (DIGEST)                 or : lightwave-digest-request@webcom.com
  63. Administrative Items To     : owner-lightwave@webcom.com